-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
featureRequest: preExtract and preUpgradeTasks configuration option. #8804
Comments
This issue has been labeled with This label will be replaced with If it's not clear what is missing to move this issue forward, ask for clarification in a new comment. If you think we already have what we need to move forward, mention this in a new comment. |
thanks for your reply. I didn't test it on Linux. So maybe. |
Back to the generic concept of Ideally they are configurable per-upgrade. We also need to consider how, where and when they are run:
|
A use case from #8984: Drupal project updates. Drupal configuration is stored in Git, but updates from Drupal core or modules can modify it. To achieve completely automated updates we need:
|
For the above Drupal config use case:
Ideally before any changes are made. And a counter question:
In the same container. In the post-upgrade task we need to have the database (sqlite) generated in the pre-upgrade. |
Please explain why Drupal needs to be installed prior to updating dependencies. Keeping in mind that Renovate updates dependencies directly. I normally would not see any reason why a command needs to be run prior to us editing the e.g. |
That's the way it works 🤷 Drupal, as a usual CMS, consists of two parts: code and database. But there is also a third one: configuration. The active configuration lives in the database, but it can be exported to (or imported from) yaml files. The best practice is to not change any configuration on prod, but rather update it in dev/local environment, export to Git and then deploy to prod where it will be imported. (So code and config are stored in Git. Database is not. To run tests in CI, we install Drupal importing the configuration from Git. Same as for local development.) Drupal core and modules sometimes provide their own config, which is still can be edited by users. Modules can provide updates which can modify the active configuration. They never touch the exported one (because, even if it's the best practice, the exported config may not exist). So module updates need to be executed within an active Drupal installation. Also, losing the config updates is not that critical because they come rarely. I guess most of people don't even notice the loss 😅 |
Define "module updates"? We are literally editing a text file. I think you're referring to some command someone would normally run? |
Oh, yes, sorry. So a module release can provide one or more update functions which need to be executed after the code update. I think the most common word for this would be "migrations". But in Drupal they are called updates. |
We have a similar problem. We use A |
IMHO this it out-of-scope of renovate and better suited for a CI task.
I argue that moving (complex?) tasks from a CI pipeline into Renovate pre/postUpgradeTasks is an anti-pattern. |
FWIW I think we need to consider semantics similar to |
Another potentially-related use-case here would be for Phoenix projects. The default setup for Phoenix does not allow for Renovate to update your node_modules since some of your dependencies are generated files; you need the Phoenix buildchain to generate them before you can run Basically, that's because Phoenix always adds the following to your
and those In this case, we don't actually need Renovate to manage those dependencies, so being able to either remove these dependencies before renovate runs OR run the mix compilation would do the trick. To put that into psuedo-code, you could imagine making this work with one of the following two options:
|
We have another use-case in our project where some of the files are generated by openapigenerator( these are the files which aren't committed in git). renovate scans the repo and remove the dependencies from go.mod as it doesn't see any file which is using the dependency. Is there any way we can achieve this now with current self-hosted configurations ? |
I can't think of any way to achieve it now |
So i tried with below configuration: But still go.mod removes packages which are part of generated files. Am i missing something here? |
@Himani-relan I haven't found a way yet to solve the generation problem. |
Practically the same usecase as @Himani-relan, we use ent as our entity relation framework and for go get not to fail, a call to |
Same here, some assets files are embedded in the go binary by generating go source files with https://github.com/go-bindata/go-bindata. |
We have another use-case for which we would need pre-upgrade tasks: We would like to be able to provide "migration scripts" based on OpenRewrite which modify the source code via AST. The migrations would be selected based on the source and target versions as determined by Renovate. These migrations need to be executed before Renovate updates the dependency, because otherwise the source may contain unresolved references in the code, which cannot be migrated. |
I'd like to hear more about this, because I'd always assumed migrations would occur after the dependency upgrade. For example let's say the new version renames an API function. Would you migrate the code to the new API function name before updating the dependency? |
Yes. The AST-based tools typically require a fully resolved AST to operate on, so that a referenced symbol can correctly be resolved while respecting overloading concepts the language may have. After the migration the references would resolve against some stubs. As a workaround I will try to use the Git stash. Will that work? |
It might, but also don't forget you may need to run an install after stash and before migration? |
Not sure what the "install" is you are referring to. Naively I was expecting that I would only have to restore the changes made by Renovate using |
I assume you might be doing Java? But if it were JS for example then I was going to guess you'd need your node modules populated with the "old" dependencies before you ran the migration. BTW I'm interested in incorporating OpenRewrite into Renovate natively so feel free to reach out to me separately on the topic so we don't flood this thread. |
I'll copy in my use case, as I duplicated this issue! My team is running renovate against some golang repositories. We have set Example: |
So would those commands be executed before we run any |
Yeah exactly - the |
So it would be something like this?
|
Exactly :D |
Found a workaround : manually git clone in the cache dir, then execute your command then renovate current=$(pwd)
rm -rf ./baseDir
mkdir -p ./baseDir/repos/bitbucket-server/myproject/myrepo
git clone ssh://mybitbucket.com/myproject/myrepo.git ./baseDir/repos/bitbucket-server/myproject/myrepo
cd ./baseDir/repos/bitbucket-server/myproject/myrepo
go generate ./...
cd $current
docker run --rm -v "$(pwd)/baseDir:/tmp/renovate" -v "$(pwd)/conf.js:/usr/src/app/config.js" renovate/renovate And your configuration must have |
We have another use case for this -- we don't check-in generated go protogen files, but they are needed to run |
Same when using sqlc. |
Add an option to specify a docker command and a docker user. It is useful if you need to customize your image before running `renovate`. It maybe a partial option for renovatebot/renovate#8804 The idea start from this discussion renovatebot/renovate#23500
Same when using wire which generates dependency injection code. In my case, we have some dependencies listed in |
Let's expand this to be more generic and allow arbitrary tasks to be executed at any state where it's useful, e.g. postClone/preExtract, preUpgrade, postUpgrade, postPrCreation, etc. |
Just to chime in: having a preUpgrade hook would most probably solve Yarn package updates when combined with Symfony UX packages. Currently, a package upgrade would fail due to a package not being installed as it comes from a composer dependency. Being able to run composer install before the upgrade would most probably solve this.
|
Adding postCommit/prePrCreation as well might be a +1. It will allow tools to modify CHANGELOG.md file based on commits. |
I opened a discussion about this same problem before seeing this issue, sorry! I've since closed that discussion. We use syncpack to enforce certain rules about dependencies in our monorepo. That has to run before calling |
This comment was marked as spam.
This comment was marked as spam.
This feature has label |
What would you like Renovate to be able to do?
We try to create PR for CocoaPods managed dependency, but renovate display error like this.
yes, we are not putting xcodeproj file in git repository.
instead, using
xcodegen
https://github.com/yonaskolb/XcodeGen to create xcodeproj file from cli before we build the project.Did you already have any implementation ideas?
like the
postUpgradeTasks
https://docs.renovatebot.com/configuration-options/#postupgradetasks configuration, we want to execute arbitrary commands bypreUpgradeTasks
to prepare for renovate.The text was updated successfully, but these errors were encountered: