Skip to content
This repository has been archived by the owner on Jul 25, 2024. It is now read-only.

Solution to automatically merge upstream changes #22

Open
cedric-anne opened this issue Dec 21, 2022 · 4 comments
Open

Solution to automatically merge upstream changes #22

cedric-anne opened this issue Dec 21, 2022 · 4 comments
Assignees

Comments

@cedric-anne
Copy link
Contributor

cedric-anne commented Dec 21, 2022

I recently worked on a solution to automatize merge of upstream changes and I think I have arrived at something that should make it possible to limit manual interventions as much as possible.

I based my work on a clean fork of docker-library/php repository, applied some patches on Dockerfile-linux.template template and declare -dev versions in versions.json file, in order to be able to automatically update -dev images files using apply-templates.sh script when upstream changes are merged.

Job has been done on the master branch of my cedric-anne/docker-library-php fork that does not yet contains latest upstram commits. It should trigger an automatic merge on midnight and an automatic build of images one hour later.

I did not create a pull request as it would not be easy to read due to a complete rebase on docker-library/php repository.

I splitted my job in 5 commits.

  1. https://github.com/cedric-anne/docker-library-php/commit/c7fc99ac9d99311d41d64d79344eddbd4758d05a
    This commit just disable the initial CI workflow of the docker-library/php repository. Indeed, we cannot reuse it.

  2. https://github.com/cedric-anne/docker-library-php/commit/c2def05326644602330ceface5aa136897b948c1
    This commit contains Dockerfile-linux.template patch, declaration of -dev versions in versions.json file, and the daily build workflow.
    I tried to made as less changes as possible on Dockerfile-linux.template file to prevent conflicts that would require a manual intervention.
    On versions.json file, I had to put versions at the beginning of the file to prevent conflicts. Indeed, *-rc versions are constantly changing from null to a json object (see docker-library/php@b8abf7a and docker-library/php@67c242c), so putting something on previous or on next line will result in conflicts everytime this kind of change will be done. Conversely, putting -dev versions right before the 8.0 version line should not result in any conflict, except when this 8.0 version will be removed.
    I tried to put -dev versions in a dedicated files, but it required too many changes and it finally did not seem like a good solution to me.

  3. https://github.com/cedric-anne/docker-library-php/commit/6ec502c300194ecf4e721838dac812944c85768e
    This commit contains the workflow used to automatically merge upstream changes.
    In order to be able to push on the master branch, that is a protected branch, I had to generate a Personnal Access Token on my account to be identified as an administrator account. The only other solution would be to generate a PR everytime there is something to merge. It is easy to do, but it would result in something less automated.

  4. https://github.com/cedric-anne/docker-library-php/commit/a3085731c75a76e40d25b92b9f37e5b116149f8f
    This commit contains the README file update and corresponding git attributes to prevent any conflict on this file during merge of upstream changes.

  5. https://github.com/cedric-anne/docker-library-php/commit/4c7c5c5571eb4700650e766d07b015829b151d1a
    This commit contains only changes made automatically by apply-templates.sh script.

@cedric-anne
Copy link
Contributor Author

Hi,

Are you interesting in this automerging logic? Instead of pushing into master, it can also create PRs, so they can be validated manually.

The automerging action failed this morning (see https://github.com/cedric-anne/docker-library-php/actions/runs/3851543403/jobs/6562832790) due to the fact that *-rc versions were deleted from upstream (see docker-library/php@8ca1f9e). It produces merge conflicts, and it seems that is not possible to simply ignore conflict on deleted files using .gitattributes as I did for the README.md file (see https://stackoverflow.com/questions/11331494/git-merge-strategy-to-ignore-deleted-files). But, is seems possible to implement a simple script that would ignore such conflicts on autogenerated files.

@jdecool
Copy link
Member

jdecool commented Jan 6, 2023

Hi @cedric-anne, sorry for the delay of this answer.

It looks like very interesting, but I'm too busy to implement it right now.

I keep this issue, to work on it later.

@jdecool jdecool self-assigned this Jan 8, 2023
@cedric-anne
Copy link
Contributor Author

Hi,

I finally got a solution to have a really low probability of conflicts, by preventing modifications on autogenerated files that are not used here.

So, on my fork (https://github.com/cedric-anne/php-daily), there is now a scheduled task that, merges changes from upstream, push this in a new branch and opens a PR that contains the changelog (see https://github.com/cedric-anne/php-daily/pull/12, https://github.com/cedric-anne/php-daily/pull/14, https://github.com/cedric-anne/php-daily/pull/15, https://github.com/cedric-anne/php-daily/pull/16).
If it fails, it creates an issue to warn about it (see https://github.com/cedric-anne/php-daily/issues/10 / https://github.com/cedric-anne/php-daily/actions/runs/4337608124/jobs/7573728096, that correspond to a force failure).

Schedule configuration was not correct at first, but is now twice a month, so that lets 2 weeks to check changes and, eventually, resolve conflicts, before a new PR is created.

This solution is based on smallest possible patch of the docker-library/php files, in order to make it as easy to maintain as possible.

If you approve such a solution, you can force-push the master branch of my fork on phpdaily/php repository and you will get up-to-date docker containers, including thoose for PHP 8.3.

@jdecool
Copy link
Member

jdecool commented Apr 7, 2023

That look awesome work !

I'll take time to look at your work and then I'll happy to merge it in this main repository.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants