Enhance script for feature branches

The workflow just is for the develop branch.

We also need it for feature branches, because we want to create a package from that feature branch. Otherwise, we cannot test and cannot add it in one of our projects composer.json for testing. E.g. the pipeline of the mobimo component project does not run anymore.

I will add $CI_COMMIT_BRANCH == "develop" $CI_COMMIT_BRANCH == "/^feature/.*" for the rules.

@jurgenhaas Can you confirm? Then I will do the job.

@danielspeicher that's a great idea. Should that be done as a second rule then?

@jurgenhaas Yes, a second rule would be:

rules:
    - if: $CI_COMMIT_BRANCH == "develop"
    - if: $CI_COMMIT_BRANCH == "/^feature/.*"

Correct?

Looks about right.

mentioned in commit 3076d7b0

mentioned in commit 0d6b1ee5

I have also added tags, that a composer package can be created.

rules:
    - if: $CI_COMMIT_BRANCH == "develop"
    - if: $CI_COMMIT_BRANCH == "/^feature/.*"
    - if: $CI_COMMIT_TAG

closed

@danielspeicher that's a bit unfortunate, because that means that also all the tests run again for tags. Ideally, only the composer packaging should be running in that context. Is that possible?

reopened

@danielspeicher Yes, that is true. It should only build a package (we need a tag here) after all the tests are successful. So, I think the tests should run, when committing a tag.

Or do I miss something here?

The tests should run, when code gets committed.

When a tag gets added, that only happens to successfully tested code, we don't have to test the code again at that point. We only need to build the composer package.

What happen when:

1. I commit a change and the tests are failing
2. I commit a tag, so no tests are running

Then we have an untested package.

I have the idea to make the pipeline smarter. A commit of a tag should check, if the last pipeline with tests was successful. Then a package based on hat can be created. Currently, this is not the case.

But there I need some discussion or help.

The problem with the tags is, that if a tag is created, it is there and the tests for the tag would run afterwards, i.e. after the tag has already been created. Then the tests are coming too late anyway.

The workflow, as it should be, I guess, looks like this:

• Tests are running for the develop and all feature/* branches on each commit or manuelly.
• Merging into main from develop is only allowed, when the pipeline succeeded; otherwise that should be forbidden.
• When merging into main, no tests are necessary, and a tag should be created automatically.
• Other ways of creating tags should be forbidden.

@danielspeicher does that make sense? Is any use case missing?

added Doing label

assigned to @jurgenhaas

Sounds great.

Do we cover the following workflow, I had to do with a Mobimo module?

• I created a feature branch for the module, like we did now for the D10 update
• Now I wanted to integrate it into the composer.json of a portal project to test
• There we need a composer package, at least for the deployed feature version

That is why I created tags with a specific name, that it do not conflict with the version numbers. (Not the best solution, I know, but there was nothing else I know of)

So, I think we need a solution for feature versions (there can be more than one).

Or do I now miss something? Or is there any other way to integrate a feature module?

Or can we enhance the build to create a package for a feature just like develop. One version is enough I think. Not what I mentioned in the last post.

Ah I pulled. Is this already working?

Then just forget my posts

Since the regex syntax for the rules in our GitLab templates got fixed earlier today, it now also builds composer packages for feature branches. They can be loaded just like any other branch or tag from any repository. To find out, how a specific package version is being called, you can always call composer show NAMESPACE/PACKAGENAME -a which shows all available versions.

So, that said, I start implementing the logic described above so that the process gets automated, and we protect the tags, that nobody creates any by mistake.

mentioned in commit 1d5049bd

mentioned in commit 38ea3b25

mentioned in commit bad8ab94

mentioned in commit d565b42e

mentioned in commit c6995e79

@danielspeicher this should now be working as designed.

• The test templates only get included for commits on develop or feature branches, but not for merge requests or new tags.
• The build package template gets included after successful tests, but also for merge requests and for new tags.
• A new tag gets applied automatically, when develop or release get merged into main.

We could also protect manual tagging, but I suggest to leave that open for now, just to keep it simple - we should be careful and not add tags manually.

closed

removed Doing label

mentioned in commit 01c14461

mentioned in merge request !5 (merged)

mentioned in commit 1027123f