Renovate autocloses PRs that it created when there are config changes in renovate.json file. Is there any way for renovate to reopen those PRs?
There was a PR 'X' that renovate created, which didn't pass some of the checks. some configs in renovate.json were later changed and due to this, renovate autoclosed 'X' PR.
How can we make renovate reopen/ create new PR 'X' for the same version upgrade? Checking the If you want to rebase/retry this PR, click this checkbox. checkbox did not work, the PR 'X' still remained closed, and the branch it created for the PR is deleted.
I think you are looking for recreateclosed.
Related
I'm not able to delete a 2sxc view. getting a warning
"Had an erro talking to the server (status 400).
Massage:Bad Request
Detail:found 2 relationship where this child - the parents are:3854 (2sexyContent-ContentGroup), 3897 (2sexyContent-ContentGroup)."
Please find warning image attached.
This means the template is still in use. You can either find out where exactly, delete the module and the dnn-trash, then you can delete.
Alternately you can force-delete it (not recommended). To Force-delete, go to "Data" and switch to debug-mode and change scope to "2SexyContent-System" http://2sxc.org/en/blog/post/advanced-dynamic-data-content-understanding-content-type-scopes.
There you'll find the content-item describing the template, which you can delete, and force-delete.
I have a table with different methods, for example, one of them is validateWrite, when setting Field A to value X, Field B and C has to be filled in.
Suddenly (without changing code, I have compared the code with the test enviroment, it does work there) the validateWrite has stopped working.
I have tried to recompile the table, but that did not work.
Any idea why it suddenly (without making other modifications in this enviroment, or generating a CIL) stopped working and what i can try to solve it?
If some piece of code is calling table.doInsert(), it skips the validateWrite() method.
If the environments are truly identical, then I would try closing your AX client and deleting your user caches (see http://dynamics-ax-live.blogspot.com/2010/03/more-information-about-auc-file.html) where you delete all of the *.auc files located at C:\Users\[Username]\AppData\Local
In addition to what that tells you to delete, I'd also remove the *.kti file and all of the files & folders inside of C:\Users\[UserName]\AppData\Local\Microsoft\Dynamics Ax
Then open AX, see if the problem still exists. Then full system compile, CIL build, and delete your usage data.
The preferred route though would be to just drop a breakpoint in and debug the code to see what the execution stack is.
Using Django 1.8 with a SQLite database.
I made a change in models.py that consisted of eliminating two out of four elements from a field choice and editing one of the remaining two:
Original value:
OPTION_INSPECTOR = (
('John Smith', 'John Smith'),
('Taylor', 'Taylor'),
('Hale', 'Hale'),
('James', 'James'),
)
New value:
OPTION_INSPECTOR = (
('John Smith', 'John Smith'),
('Greg Taylor', 'Greg Taylor'),
)
I then ran:
python manage.py makemigrations my_app
I saw nothing unusual, only the changes that I made, if I recall correctly. I do not have the actual output.
Then I ran:
python manage.py migrate my_app
Again, I don't remember anything unusual. But, the model hasn't changed the choices within the dropdown menu on the Admin site. Can anyone suggest a way to make this change successfully?
Thanks!
I am continually changing my app based on feedback from researchers. I have had a lot of issues like what you are describing. I have found that there are a lot of changes I can make to the models before the app total breaks and I have to go back and "remake" it with a fresh model.py file, but eventually, that is what I have had to do. In the meantime (before I remake the app), I make the changes to the model.py, then I run the makemigrations and then migrate. I look and see what the errors are and I make the changes to fix them directly in the database (in my case, MySQL). Typically, I have to do this to add or alter fields. Then, I rerun the make migrations and the migrate, and I get warnings about duplicate fields, but the app keeps working. Like I said though, eventually, I have to remake the app with a fresh model.py file to get rid of all the warnings.
I have a Plone 4 site which stopped to rename new Archetypes objects; after creation (as something like /temp/portaltype.2015-04-23.1234567890) and saving the first changes, including giving it a title, it should be renamed to something nicer (/temp/an-object-with-a-meaningful-name), but this doesn't happen anymore.
Perhaps the problem arose when I applied some changes to update Plone from 4.3.3 to 4.3.4 (to make one step at a time); but I have inherited a long versions.cfg which is solely sorted by package names and doesn't include any hints why certain versions were chosen ...
I'm able to go back two months and have a version which does the renaming, but without more knowledge about what to look for, it will be a very time-consuming process of re-applying every single change, rebuilding, starting and testing; but there have not been any changes to my schema definitions. I have a temp browser which is involved in delivering the primary edit form. but this doesn't seem to be the case for the saving action.
Sadly I don't fully understand yet the mechanisms of the base_edit action which should - as far as I understand - call Archetypes.BaseObject.processForm and implicitly ._renameAfterCreation, so I'd be grateful for some pointers how to debug this. Thank you!
Update:
I have a few triggers in my product's configure.zcml, e.g.:
<subscriber
for=".content.portaltype.PortalType
Products.Archetypes.interfaces.IObjectInitializedEvent"
handler=".events.onInitPortalType"/>
… with, in events.py:
def onInitPortalType(self, event):
"""
Called after first edit of new objects?
"""
print '/// onInitPortalType(%(self)r, %(event)r)' % locals()
setInitialOwner(self, event)
setStateToPrivate(self, event)
However, the event doesn't seem to be triggered, since I couldn't find the output in an instance fg session.
Update 2:
I noticed that zope.event had been pinned to a quite old version (3.5.2), so I'm trying to update to 4.3.4 more seriously now (following this how-to). This got me zope.event v4.0.3, but I have a version conflict now:
There is a version conflict.
We already have: zc.recipe.egg 1.3.2.
While:
Installing.
Getting section test.
Initializing section test.
Installing recipe zc.recipe.testrunner.
There seems to be a requirement for zc.recipe.egg < 2dev somewhere, but I can't find it.
Nothing significant changed between Plone 4.3.3 and 4.3.4 on Archetypes. Products.Archetypes changed from 1.9.7 to 1.9.8 and Products.ATContentTypes remains on the same version.
Pointers could be:
There's a _at_rename_after_creation flag, which is True by default. This can be changed on the content type class.
Is your type still activated in portal_factorytool? (Afaik this should have no impact on renaming after creation - but who knows :-))
Any Products.Archetypes.interfaces.IObjectInitializedEvent subscriber?
Issue I had once was, that the tmp id portaltype.2015-04-23.1234567890 had the wrong format and AT did no recognise it as tmp id and therefore it did not rename it after creation. The method AT uses to check if the id is autogenerated --> https://github.com/plone/Products.CMFPlone/blob/4.3.4/Products/CMFPlone/utils.py#L111 AFAIK the problem was, that the meta_type and portal_type was not the same anymore.
I want to delete this red-marked target, but am unable to.
The "minus" button in the dialogue remains greyed-out, it doesn't respond to backspace or delete keys and right-clicking just brings up help options. I can drag the missing-red-marked target above or below the working black target, but it doesn't let me delete it.
This missing red target only seems to appear in this edit schemes dialogue.
In my main project/target window, I just have the one good target there.
Any ideas how to clean this up and delete this missing target?
What worked for me was to designate another executable (or none) in the existing scheme's various actions (run, test, etc.). It's the fact it's in use in the scheme's actions that prevents its deletion. I discovered this during my research for Mastering Xcode 4 (yes, shameless plug). :-)
Try creating a brand new scheme (via "New Scheme" or "Manage Schemes...") and start using that.
Once your new scheme is building properly and is set as a default, you should be able to delete the old scheme with the bogus "missing" target.
The real issue here is explained by Joar Wingfors in the Xcode-users mailing list (emphasis mine):
In the scheme sheet you cannot delete things from one tab that some
other tab depend on. In this case you probably have to delete the
target from the test tab before you can delete it from the build tab.
Or something along those lines.
I had the exact same problem. Solved by closing the xCode and externally editing the schema file to delete the bundlableResource section for the missing library. Not the safest of all methods but it works.
First delete all schemes and then generate the schemes again. Work for me .
What Joshua said, a bit tailored. Go through all various actions and change the missing executable to an existing one.
In your case, go to 'Profile' and switch to the new app. Same if you encounter this in 'Test' tab.